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SERVICE CENTER STANDARDS 


INTRODUCTION 


This note is a statement of our views on service cen- ter 
standards. It is an input to the service center panel discussion of 
the October Network meeting. Some areas are identified for 
consideration in intra-network standardiza- tion. We do not describe 
a methodology for analyzing com- puter systems; however, such analysis 
may be appropriate for solving the problems. We also do not enumerate 
the spectrum of services that may be required. We merely enu- merate 
areas where commonality of appearance and function can be of immediate 
value to a network user. 


CAVEAT 


It is assumed that service centers will conform to official 
network standard protocols. This is essential for service centers 
since the effects of their practices are generally more wide-spread 
and are crucial to the effectiveness of minimal hosts such as TIPs. 


JUSTIFICATION 


The generation of network standards for service centers is of 
value to a very important class of people--the ultimate user 
community. We have such a community at Rand that is composed of 
research scientists and their support programmers. Certainly such 
users exist elsewhere, and a goal of the net- work must be to 
encourage their use. In the past, these researchers have relied 
solely on programmers to buffer them from computer detail. 
Standardization of services is cer- tainly a great value in expanding 
the community of users and eliminating the buffer. 


Additionally, standards will be of benefit to those persons 
responsible for implementation of resource access programs. Instances 
and areas of standardization are cited below to support both of these 
statements. 
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AREAS FOR STANDARDIZATION 


Each host installation has its own standards for pro- gramming 
and operational procedures. From a network point of view, we are only 
interested in standards affecting external performance--primarily 
required operations and documentation of procedures. Intra-network 
standards should allow a user to plan his network use effectively to 
improve the performance of his tasks and take advantage of savings in 
both time and money. 


Remote Job Entry 


One immediately apparent area for standardization is in the 
access to network resources. For example, there are two remote job 
entry (RJE) facilities on the network at present with two different 
data protocols. The UCSB facility was developed early to provide 
timely access to their resources. The UCLA facility was developed 
after the Telnet and Data Transfer protocols and takes advantage of 
them. If these two services appeared alike to the user and to the 
using process, two significant advantages would be obtained. First, 
the using system would need only one module to access both facilities. 
And secondly, a user could select either facility on a dynamic basis 
using the conditions influencing him at any given moment without any 
additional knowledge of the specific site. 


Login Procedures and Subsystem Access 


A more global example of common access to resources is the login 
procedure to remote systems. All systems require basically the same 
information--password, identification, account number. Yet the 
formats are syntactically inconsis- tent. An extension to the logger 
generally exists at these sites in the form of a "line scanner" for 
the network. In general, this module also performs other 
transformational functions. It would certainly be reasonable for this 
module to translate a network standard login into whatever format was 
required at the site. Perhaps to a lesser extent, a similar approach 
could be taken to constructing a uniform access to subsystems from the 
supervisor. In like fashion, a network standard interrupt could be 
translated into the escape (e.g., control C) of the serving host to 
return from a subsystem. 


Charging Algorithms and Accounting Protocol 


To accurately forecast costs, a normalized formula for machine 
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time estimation is needed. Technically, an accounting protocol is 
easily added at the subnet and/or NCP levels--the relevant information 
is the same for all nodes, thus the Net charges are readily determined 
by any node. More difficult is the prediction and comparison of host 
charges. Like the login procedure example, each host uses the same 
ingredients, namely storage, I/O, connect time, and CPU resources 
expended. Again, like the login procedure the information is handled 
slightly dif- ferently in each case such that estimations are 
difficult. For example, some charge algorithms represent I/O as 
counts of I/O transactions where others clock I/O time. Without 
Significantly perturbing anyone’s local accounting proce- dures, it is 
desirable to normalize the charge components as a step toward 
reasonable cost comparisons and forecast- ing. 


Off-Line Services 


Procedures need to be established for off-line services where 
they are offered as a service or are an integral part of a service. 
Such services are graphic hardcopy, large quantities of printer 
output, tape or disc facilities, etc. How are such items transmitted? 
What guarantees or state- ments should be made about turnaround times? 
How should they be specified--in terms of invocation and communication 
with operations staffs? 


Job Scheduling, Priorities and Status Information 


Extrapolating from the above rather static cost com- parisons 
that a normalized formula allows, envision a small but useful process, 
i.e., a throughput query service, that allows the user to dynamically 
determine the most cost ef- fective location for a job. (Such a 
service is technically reasonable since some systems now offer status 
data such as a core map and job queues display.) Imagine the user’s 
Situation. "Let’s see, I need these numbers by 4:00 and I’m willing 
to pay a slight dollar premium to get them; the job will run on any 
Tenex machine, where should I run it?" The user would like to query 
Tenex systems, providing as input the requirements of his program, and 
get answers like probable turn-around time and cost vectors for dif- 
ferent priorities. (Incidentally, our non-programmer users are 
familiar with their job parameters (time, core space, etc.) since this 
information is normally part of the out- put stream.) 


Most of the necessary elements for such a service are readily 
available in systems with which we are concerned. The query service 
would be a utility for users. This is the kind of a problem we should 
address concerning services vis-a-vis exporting Network concepts. 
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Other Areas 


In addition to the above items, the user community could 
immediately benefit from standards in: documentation formats and 
distribution, operating schedules, the extent and availability of 
consulting services, data transmission and storage facilities, 
techniques for communication with operations staffs, and abnormal 
procedures such as system or program failures. 


Some of the above items should be described in a standard format 
rather than the services themselves being standardized across the 
network. For example, schedules obviously vary in different time 
zones and each system has a different magnitude and policy for on-line 
storage capabilities. 


To some extent these items are covered in the Resource Notebook. 
It should either be expanded to become a service center standards 
notebook or a separate item to fulfill that function should be 
created. For example, a site might have resources that it wished to 
offer on a limited or special arrangement basis to the network 
community and should be included as such in the Resource Notebook. 
However, that site might not wish to or have the staff to conform to 
network service center standards. Hence, the service center notebook 
would describe standards for a much more rigor- ously conforming 
community. 


The theme of this note is that without classifying ser- vices and 
analyzing operations at service nodes, there are a number of areas 
that can be standardized to some extent throughout the network. What 
is needed is a manual of service center standards and a collection of 
documentation on services. Perhaps the latter is the Resource 
Notebook. 


Service centers who intend to attract a significant network user 
community should be prepared to adopt a psychol- ogy appropriate to 
the market-oriented requirements for providing service. In the 
network at large, with our re- search orientation, personnel tend to 
have a different approach to computing than that required by a service 
bureau. 
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